K8S（三）：Pod入门基本概念，网络和存储共享，Infra/Pause容器

1-1：Pod是什么（1）Pod 是 kubernetes 中你可以创建和部署的最小也是最简的单位。Pod 代表着部署的一个单位：kubernetes 中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。kuberentes 管理的是 Pod 而不是直接管理容器。

（2）Pod 是一组紧密关联的容器集合，它们共享 IPC、Network 和 UTS namespace，是 Kubernetes 调度的基本单位。Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统（所有 Pod 内容器都可以访问共享的 Volume，可以访问共享数据，一个pod里面共享一个ip地址，不同的容器只是对应不同的端口号），可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

（3）在 Kubernetes 集群中 Pod 有如下两种使用方式：

一个 Pod 中运行一个容器。“每个 Pod 中一个容器” 的模式是最常见的用法；在这种使用方式中，你可以把 Pod 想象成是单个容器的封装。在一个 Pod 中同时运行多个容器。一个 Pod 中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。 就比如说，一个应用访问某一个数据库，那么可以直接放在一个pod里面，应用和数据库的ip就共享pod的ip。不光是共享ip网络，连pod里面的文件也将会是共享的。（4）一个node中可以有多个pod。

[root@k8s-master ~]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-85b98978db-r7nmc 1/1 Running 0 3d 10.244.2.5 k8s-node22 nginx-deployment-7c969dc4f-hn6vk 1/1 Running 0 18h 10.244.2.12 k8s-node22 pod-network-test 2/2 Running 66 (44m ago) 2d19h 10.244.1.8 k8s-node11 two-containers 1/2 NotReady 0 16m 10.244.2.13 k8s-node22

可以看到一个node上不止一个pod，从READY中，看到 一个pod里面不止一个container

1-2：Pod内部结构

为什么Kubernetes会这么设计？（1）原因之一：在一组容器作为一个单元的情况下，我们难以简单地对“整体”进行判断及有效地行动。比如，一个容器死亡了，此时算是整体死亡么？是N/M的死亡率么？引入业务无关并且不易死亡的Pause容器作为Pod的根容器，以它的状态代表整个容器组的状态，就简单、巧妙地解决了这个难题。（2）原因之二：Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume，这样既简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。

Kubernetes为每个Pod都分配了唯一的IP地址，称之为Pod IP，一个Pod里的多个容器共享Pod IP地址。Kubernetes要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信，这通常采用虚拟二层网络技术来实现，例如Flannel、Open vSwitch等，因此我们需要牢记一点：在Kubernetes里，一个Pod里的容器与另外主机上的Pod容器能够直接通信。

1-2：共享资源实现原理关于Linux的共享，就先得先知道为什么要去专门实现共享，因为Linux本身就是隔离的。就得知道namespace和cgroup。这里就单纯的简单介绍一下，因为详细内容还是挺复杂的。

1-2-1：NamespaceLinux Namespace 是kernel 的一个功能，它可以隔离一系列系统的资源，比如PID(Process ID)，User ID, Network等等。一般看到这里，很多人会想到一个命令chroot，就像chroot允许把当前目录变成根目录一样(被隔离开来的)，Namesapce也可以在一些资源上，将进程隔离起来，这些资源包括进程树，网络接口，挂载点等等。Namespace 是 Linux 内核用来隔离内核资源的方式。通过 namespace 可以让一些进程只能看到与自己相关的一部分资源，而另外一些进程也只能看到与它们自己相关的资源，这两拨进程根本就感觉不到对方的存在。具体的实现方式是把一个或多个进程的相关资源指定在同一个 namespace 中。可能绝大多数的使用者和我一样，是在使用 docker 后才开始了解 linux 的 namespace 技术的。实际上，Linux 内核实现 namespace 的一个主要目的就是实现轻量级虚拟化(容器)服务。在同一个 namespace 下的进程可以感知彼此的变化，而对外界的进程一无所知。这样就可以让容器中的进程产生错觉，认为自己置身于一个独立的系统中，从而达到隔离的目的。也就是说 linux 内核提供的 namespace 技术为 docker 等容器技术的出现和发展提供了基础条件。

总结下来就是隔离资源，不同namespace之间是相互隔离的。

1-2-2：cgroupcgroups 是Linux内核提供的一种可以限制单个进程或者多个进程所使用资源的机制，可以对 cpu，内存等资源实现精细化的控制，目前越来越火的轻量级容器 Docker 就使用了 cgroups 提供的资源限制能力来完成cpu，内存等部分的资源控制。

1-2-3：突破隔离屏障容器之间是通过namespace之间去隔离的，之间的网络是隔离的，文件系统是隔离的，难道在pod当中两个容器也不能相互通信了吗？仿佛又回到了docker各个容器之间都是隔离的。

Pod要解决网络和文件系统的问题其实就要打破namespace的隔离。

怎么解决两个容器之间通信的问题呢？也即是容器之间看到的网络协议栈是一样的，在创建pod的时候会先创建infra container这个容器，启动好之后然后再将实际创建的pod加入到infra container容器当中，这个容器实现的主要目的是维护了pod的网络，没有跑任何的业务逻辑，只是启动了一个容器罢了。其他容器的创建都让其连接至该容器的网络命名空间当中。这样一来其他容器看到的网络视图就是infra container的网络视图了。一个pod当中所有的容器看到的网络设备，网卡，ip，mac地址都看到的是同一个了，因为在一个网络命名空间。这样就解决了网络共享的问题。实际上pod的ip就是infra container的ip。（加入infra container命名空间实现网络共享，同一个网络协议栈）

1-3：Infra / Pause容器 共享网络既然说 Pod 要解决这个问题，核心就在于如何让一个 Pod 里的多个容器之间最高效的共享某些资源和数据。因为容器之间原本是被 Linux Namespace 和 cgroups 隔开的，所以现在实际要解决的是怎么去打破这个隔离，然后共享某些事情和某些信息。这就是 Pod 的设计要解决的核心问题所在。所以说具体的解法分为两个部分：网络和存储。Pause 容器就是为解决 Pod 中的网络问题而生的。

1-3-1：Pause 容器实现Pod 里的多个容器怎么去共享网络？下面是个例子：

比如说现在有一个 Pod，其中包含了一个容器 A 和一个容器 B，它们两个就要共享 Network Namespace。在 Kubernetes 里的解法是这样的：它会在每个 Pod 里，额外起一个 Infra container 小容器来共享整个 Pod 的 Network Namespace。

Infra container 是一个非常小的镜像，大概 700KB 左右，是一个 C 语言写的、永远处于 “暂停” 状态的容器。由于有了这样一个 Infra container 之后，其他所有容器都会通过 Join Namespace 的方式加入到 Infra container 的 Network Namespace 中。

所以说一个 Pod 里面的所有容器，它们看到的网络视图是完全一样的。即：它们看到的网络设备、IP 地址、Mac 地址等等，跟网络相关的信息，其实全是一份，这一份都来自于 Pod 第一次创建的这个 Infra container。这就是 Pod 解决网络共享的一个解法。

在 Pod 里面，一定有一个 IP 地址，是这个 Pod 的 Network Namespace 对应的地址，也是这个 Infra container 的 IP 地址。所以大家看到的都是一份，而其他所有网络资源，都是一个 Pod 一份，并且被 Pod 中的所有容器共享。这就是 Pod 的网络实现方式。

由于需要有一个相当于说中间的容器存在，所以整个 Pod 里面，必然是 Infra container 第一个启动。并且整个 Pod 的生命周期是等同于 Infra container 的生命周期的，与容器 A 和 B 是无关的。这也是为什么在 Kubernetes 里面，它是允许去单独更新 Pod 里的某一个镜像的，即：做这个操作，整个 Pod 不会重建，也不会重启，这是非常重要的一个设计。

1-3-2：查看pause容器[root@k8s-master ~]# docker ps | grep pause74ad370baad8 registry.aliyuncs.com/google_containers/pause:3.6 "/pause" 6 hours ago Up 6 hours k8s_POD_coredns-6d8c4cb4d-nqxpc_kube-system_c4471296-3f3b-427f-9bc8-3c04fb0c39d9_15f4f5c8754301 registry.aliyuncs.com/google_containers/pause:3.6 "/pause" 6 hours ago Up 6 hours k8s_POD_coredns-6d8c4cb4d-wqrvz_kube-system_a8c5b699-1975-4df4-97f6-2c4afc6fcf33_141278cf054e8f registry.aliyuncs.com/google_containers/pause:3.6 "/pause" 6 hours ago Up 6 hours k8s_POD_kube-flannel-ds-f2s7q_kube-flannel_d706103e-c298-4fc8-aaba-b922d8e1a406_33f88e2d55d35 registry.aliyuncs.com/google_containers/pause:3.6 "/pause" 6 hours ago Up 6 hours k8s_POD_kube-proxy-pt6bp_kube-system_4ea48f14-9c94-4176-9e30-c1abcc75d4f9_33c02c3476762 registry.aliyuncs.com/google_containers/pause:3.6 "/pause" 6 hours ago Up 6 hours k8s_POD_etcd-k8s-master_kube-system_22ab7a56e143c3744d97e50cfbb349fe_3478e3ab8d898 registry.aliyuncs.com/google_containers/pause:3.6 "/pause" 6 hours ago Up 6 hours k8s_POD_kube-scheduler-k8s-master_kube-system_15086819666e30db9a1ae213350c3f24_39d93da7c2cdc registry.aliyuncs.com/google_containers/pause:3.6 "/pause" 6 hours ago Up 6 hours k8s_POD_kube-controller-manager-k8s-master_kube-system_2c3ad0e37c5de9d3c21807581aa87e6d_334f126b9b8a5 registry.aliyuncs.com/google_containers/pause:3.6 "/pause" 6 hours ago Up 6 hours k8s_POD_kube-apiserver-k8s-master_kube-system_8ed280f6defcfb993b8d22d42916f8fd_3

1-4：同 Pod 内的容器使用共享卷通信如何实现一个pod里面两个容器去共享一些数据呢？我们使用官网的一个例子，具体之后PVC等共享，我们之后出一个文章专门研究起来，这里只是让你知道，可以共享。

apiVersion: v1kind: Podmetadata: name: two-containersspec: restartPolicy: Never volumes:

containers:

name: nginx-container image: nginx volumeMounts:

name: debian-container image: debian volumeMounts:

command: ["/bin/sh"] args: ["-c", "echo Hello from the debian container > /pod-data/index.html"] # 手动往/pod-data里面存放一个文件

创建pod

kubectl apply -f volumes-share.yaml

如何查看是否成功呢？

kubectl exec -it two-containers -c nginx-container -- /bin/bash

进入到nginx-container这个容器中去，如果成功就可以看到 /usr/share/nginx/html/index.html这个里面的内容。

cat /usr/share/nginx/html/index.html Hello from the debian container

1-5：Pod生命周期Pending: API Server已经创建该Pod，但一个或多个容器还没有被创建，包括通过网络下载镜像的过程。Running: Pod中的所有容器都已经被创建且已经调度到 Node 上面，但至少有一个容器还在运行或者正在启动。Succeeded: Pod 调度到 Node 上面后均成功运行结束，并且不会重启。Failed: Pod中的所有容器都被终止了，但至少有一个容器退出失败（即退出码不为 0 或者被系统终止）。Unknonwn: 状态未知，因为一些原因Pod无法被正常获取，通常是由于 apiserver 无法与 kubelet 通信导致。参考文献Kubernetes Pod 资源共享实现机制